\section{Introduction}
\label{introduction}
True to its name, the \textsl{waterfall software development model} develops
software like a waterfall: the 
development process appears to flow downwards.  This methodology steps through requirements
capture, analysis, design, coding, and testing as part of a plan-driven approach that 
has been around since the early 1970's.  It is still the primary methodology taught 
in schools.  

The waterfall model runs the risk of failing in multiple areas of the development 
process though.  This methodology is not prepared to handle change.  
Customer requirements can change, new technologies can emerge, and competitors
are always looking to take advantage of one's miscues~\cite{sustainable}.  Without the ability
to adapt to change, the waterfall methodology can fail.  Another downfall of 
the waterfall method is the amount of time it takes to fully integrate and test at the 
end of the development cycle.  This portion of the development cycle has the potential to 
last years.  These months or years at the end of the development process are
usually never 
accounted for at the start of the process, resulting in an unhappy customer.  

The software development community is ready to explore a faster development
process that is adaptable to change. In the mid 1990's, the agile software
development
movement was born.  The agile development process was developed to adapt to change fairly 
easily.  Through the practice of iterative
development, software is produced with the most important features first.  By keeping software
in a releasable state, customers have the ability to give real-time feedback of the
current software build.  

At the heart of agile software is testing.  Rather than wait
to test at the end of the development cycle, agile practices include writing unit tests before 
any coding is done and continuously running tests in an automated fashion to give the
developer confidence that the software in its current state is behaving as
expected. The practice of
test driven development and automated unit testing saves the integration and testing 
headaches commonly seen with the waterfall methodology.  

Some in the software 
industry consider agile development to be unplanned and undisciplined.  However, agile
developers do take the time to plan and document their software.  Many times, the 
documentation is the software itself.  This allows the developer more time to focus
on creating working software rather than the ceremony of writing lengthy documents.  

Much of the work done with the agile software practices involves adapting these practices
to an object-oriented programming environment.  The main focus of this paper though will 
be to study these practices in general as well as applying them to a scripting
language environment using the Tcl scripting language.  It
will also show how these practices can be applied in industry where the process to
develop 
software can be long and tedious.  A brief description of each practice and any
difficulties adopting the practice in industry are described.  

An agile developer must be comfortable writing unit tests and 
running unit tests in an automated fashion.  The Tcl scripting language does not offer a
fully functional unit testing framework when compared to other programming languages.  
As a result, the ``t-unit'' framework has been developed for the Tcl programming language.  Kent 
Beck's JUnit framework~\cite{junitCook} for the Java programming language served as the model for 
``t-unit.''  The following procedures are available as part of the ``t-unit'' framework:
\begin{itemize}
\singlespacing
\item assertEquals
\item assertEqualsArray
\item assertEqualsList
\item assertEqualsReal
\item assertFalse
\item assertNotEquals
\item assertTrue
\end{itemize}
\doublespacing

In order to be more like the JUnit framework, an Eclipse IDE plug-in has been developed as well.  
The name of the plug-in is TUnit.  In addition to the unit testing capabilities, the plug-in has the 
ability to edit Tcl files, create new Tcl packages and files, and the ability to view the procedures 
by package and namespace; all under a TUnit perspective.  TUnit has also been
extended to work with the
Eclipse Dynamic Languages Toolkit (DLTK) plug-in.  The TUnit extension offers unit testing capabilities
to users of the Eclipse DLTK plug-in.  Finally, TUnit and the TUnit extension have been released as open 
source projects, in line with the goals of the NSF Recourse project and facilitating immediate 
availability to the software development community at large.

%% Note, once the sections are added, they will not all be labeled I
The paper is organized as follows: Section~\ref{relatedWork} explores the related work in this field.  
Section~\ref{agileSoftware} delves into the background
details of agile software development by exploring the agile culture and agile principles.  
Section~\ref{agilePractices} goes over a set of agile practices that can be used during the software
development process.  
Section~\ref{futureResearch} and Section~\ref{conclusion} 
present conclusions and recommendations for investigating further evolution of the 
project.  Lastly, Appendix~\ref{sampleBuild} shows an example build file and Appendix~\ref{sourceCode}
points to the location of the source code for the project.